chore(auth): render the Kerberos/LDAP diagnostic pages with html/template (M39) - #64

classifyUser tested u.PasswordHash != "" BEFORE the directory signal, so any
AD-backed user who also carried a local hash migrated as an app-LOCAL user keyed
by that credential. Three things went wrong at once:

  - the central ended up holding a STANDING PASSWORD for someone whose identity
    is directory-governed, so the migrated account outlived AD-side disablement,
    lockout and password policy — exactly what this package's doc comment
    promises never happens ("no record or password is copied");
  - Classify never BLOCKS a local user, so an AD population misclassified this
    way sailed straight past the "central is on a different AD" guard that exists
    to stop unauthenticatable users being imported;
  - Apply flipped allow_local_users on the target for accounts that must never
    use the app-local login path.

Composes with SA-7: that bug was one way an AD user acquired a local hash in the
first place. Fixing SA-7 reduces the population going forward but neither
eliminates it (master-admin break-glass stays legitimate) nor cleans existing
data, so this inversion is independently necessary.

Fix: resolve the directory key first; only a user with NO directory identity is
local. A KindAD entry no longer carries a password hash — the central re-binds
that person from the same AD, so copying the credential would recreate the very
shadow account this prevents. A HadLocalPassword BOOLEAN (never the hash) travels
instead so the dry run can tell the operator which break-glass logins do not
survive the move.

directoryKey prefers SAMAccountName but falls back to ldap/kerberos mappings,
because handleImportLDAPUsers provisions a user with an ldap mapping and NO
SAMAccountName until first login — without the fallback such a user is
misclassified as local or dropped entirely. The `local` provider is deliberately
not consulted: every LDAP/Kerberos JIT provision writes BOTH an ldap and a local
mapping, which is exactly how localUsername happily returned an AD username under
the old precedence.

Selection is deterministic across backends: GetMappingsForUser returns insertion
order on Bolt and UNORDERED rows on Postgres, and a user commonly carries both a
UPN and a sAMAccountName form. The bare form wins, ties break lexicographically,
so both backends produce an identical bundle.

OwnerAppID != "" short-circuits to local: an app-local user is local by
construction and must never be resolved against the directory.

Note on the two directory predicates: handler.isDirectoryBacked (SA-7) is
deny-by-default; migrate.directoryKey is an allow-list of ldap/kerberos. The
asymmetry is INTENTIONAL — one returns a verdict, the other must return a key.
Documented in both places; do not unify (internal/migrate importing from
internal/handler would invert the dependency direction).

WIRE BREAK: SchemaRev 1 -> 2. Classification happens on the SOURCE side, so a
patched central cannot trust the Kind values in a rev-1 bundle. guardMigrationCall
exact-matches the rev, so this surfaces as "upgrade the older deployment first"
rather than a silent import of buggy classification. In-flight migrations must
upgrade the source first — release notes.

Also fixed: dishonest preflight counts. Apply skips a user with no effective
roles entirely while Classify counted them as migrating, so preflight promised N
and Apply delivered fewer with nothing explaining the gap. Report.NoRoles counts
them separately with a note. The AD block checks still run for them — "the
central cannot authenticate this person" is worth saying regardless of roles.

Tests (internal/migrate/classify_test.go): directory user with a local hash ->
AD, no hash carried, HadLocalPassword set; imported LDAP user with no
SAMAccountName still directory; genuine local user unchanged and keeps their
hash; app-local user never directory even with a stray SAMAccountName;
directoryKey order-independent across insertion orders; NoRoles accounting
matches Apply. The first two fail with the precedence reverted. Full suite green.

Stacked on the H15 audience fix — same functions, same hunks.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>